API（應(yīng)用程序編程接口）可以定義為一組指令，用代碼編寫，允許通過 Internet 在軟件之間進(jìn)行通信。API 已成為整個 DevOps 流程的關(guān)鍵組成部分，不僅允許軟件和服務(wù)器之間通過 Internet 進(jìn)行無縫集成和通信，而且還改進(jìn)了整個 DevOps 流程并允許相對輕松地構(gòu)建更復(fù)雜的軟件。使用 API 所取得的成功見證了其使用率和流行度的飆升，尤其是在過去 12 個月中。

昨天的 API 攻擊與今天的 API 攻擊

由于 API 越來越受歡迎，它們已成為網(wǎng)絡(luò)攻擊的重點。僅在過去 12 個月中，API 攻擊流量就增長了 681%，95% 的公司根據(jù)研究報告報告了 API 安全事件。API 攻擊可以描述為出于惡意目的濫用或非法使用或嘗試使用 API，通常是為了非法訪問服務(wù)器以泄露數(shù)據(jù)或?qū)е路?wù)中斷。

過去，API 攻擊主要依賴于針對已知漏洞，例如 SQL 注入攻擊和 XSS 攻擊。如今，API 攻擊要復(fù)雜得多——不良行為者會戳戳刺探以了解公司 API 中的業(yè)務(wù)邏輯漏洞并瞄準(zhǔn)這些漏洞。

昨天的 API 攻擊是如何運作的？

由于 API 充當(dāng)軟件之間通過 Internet 進(jìn)行通信的網(wǎng)關(guān)，因此它們通常存儲有關(guān)實現(xiàn)方法及其結(jié)構(gòu)的敏感信息。當(dāng)攻擊者獲得此信息的訪問權(quán)限時，它可用于發(fā)起網(wǎng)絡(luò)攻擊，尤其是利用已知 API 漏洞或配置不當(dāng)?shù)?API 的攻擊。因此，當(dāng)濫用 API 的漏洞導(dǎo)致未經(jīng)授權(quán)的訪問或數(shù)據(jù)泄漏時，API 攻擊就會起作用。

已知 API 漏洞的類型以及如何防范它們

SQL 注入攻擊——SQL 注入攻擊使用特制的惡意 SQL 代碼通過 SQL 數(shù)據(jù)庫插入輸入字段，以潛在地訪問不打算顯示的信息。代碼開發(fā)不良的應(yīng)用程序更容易受到 SQL 攻擊。

XSS 注入攻擊——與 SQL 攻擊類似，跨站點腳本 (XSS) 攻擊使用惡意制作的 JavaScript 代碼插入輸入字段，以潛在地訪問數(shù)據(jù)庫并非法訪問信息。同樣，當(dāng)軟件開發(fā)不當(dāng)時，也會發(fā)生 XSS 攻擊。

推薦

應(yīng)實施輸入驗證。輸入驗證確保用戶輸入與預(yù)期參數(shù)匹配。這些可以防止 SQLi 和 XSS 攻擊。

其他類型的 API 攻擊

如今，大多數(shù)攻擊的目的是通過利用 API 漏洞獲得對服務(wù)器的未授權(quán)訪問，隨后導(dǎo)致服務(wù)中斷或數(shù)據(jù)被盜。針對 API 的一些最常見的攻擊是：

DDoS 攻擊

當(dāng)攻擊者通過同時請求數(shù)千個連接來淹沒 API 的內(nèi)存時，就會發(fā)生針對 API 的分布式拒絕服務(wù) (DDoS) 攻擊。目的是通過使可用資源無法訪問來淹沒內(nèi)存并導(dǎo)致服務(wù)中斷。雖然 DDoS 攻擊不會導(dǎo)致信息泄露，但它們的目的是阻撓。

建議——應(yīng)監(jiān)控、過濾和驗證所有入站流量。還應(yīng)實施速率限制。

中間人攻擊 (MiTM)

當(dāng)攻擊者偷偷攔截、中繼和/或修改兩個客戶端之間的請求或通信時，就會發(fā)生中間人攻擊。對于 API，攻擊者可以攔截會話令牌發(fā)布 API 和 HTTP 標(biāo)頭與用戶之間的通信。這可能會授予攻擊者對用戶帳戶的訪問權(quán)限，從而可能導(dǎo)致數(shù)據(jù)和個人信息被盜。

建議——所有網(wǎng)絡(luò)通信都應(yīng)使用 TLS 加密。TLS 確保連接保持私密，每個連接都有一個唯一生成的加密密鑰。

資產(chǎn)管理不當(dāng)

當(dāng)有不止一種方法訪問應(yīng)用程序數(shù)據(jù)庫環(huán)境時，就會發(fā)生這種類型的 API 攻擊。通常，在應(yīng)用程序的生產(chǎn)狀態(tài)期間，多個 API 端點連接到生產(chǎn)環(huán)境；當(dāng)這些端點被遺忘且未被刪除時，攻擊者就有機(jī)會使用它們發(fā)出 API 請求并可能獲得對敏感數(shù)據(jù)的訪問權(quán)限。

建議——應(yīng)正確記錄生產(chǎn)階段使用的所有 API，以便刪除多余的 API 以防止未經(jīng)授權(quán)的訪問。

通信加密不佳

傳輸層安全 (TLS) 為 Internet 上的數(shù)據(jù)傳輸提供最基本的加密形式。這確保了傳輸?shù)臄?shù)據(jù)無法以純文本形式讀取，從而在傳輸敏感數(shù)據(jù)時增加了一層安全性。加密不當(dāng)?shù)牧髁靠赡軐?dǎo)致 MiTM API 攻擊。

建議——TLS 應(yīng)該跨網(wǎng)絡(luò)使用，因此網(wǎng)絡(luò)流量是加密的，因此在 MiTM 攻擊的情況下，攻擊者無法讀取數(shù)據(jù)。

過多的數(shù)據(jù)暴露

Web 應(yīng)用程序使用 API 定期處理和傳輸敏感數(shù)據(jù)。因此，可能會發(fā)生數(shù)據(jù)泄露，通常是在 API 未在響應(yīng)到達(dá)客戶端之前對其進(jìn)行過濾時。數(shù)據(jù)泄露可能導(dǎo)致未經(jīng)授權(quán)訪問信用卡信息、會話令牌、密碼、私人健康信息等信息。

建議——應(yīng)過濾和驗證所有 API 調(diào)用和響應(yīng)，以便只允許授權(quán)的請求和響應(yīng)通過。

損壞的用戶身份驗證

API 認(rèn)證是一項核心服務(wù)，用于識別和授權(quán)客戶端訪問應(yīng)用程序。當(dāng)會話和憑證管理都存在弱點時，就會發(fā)生用戶身份驗證失敗的情況。這可能導(dǎo)致身份驗證令牌被盜，進(jìn)一步使攻擊者能夠使用它們來暴力破解 Web 應(yīng)用程序或獲得未經(jīng)授權(quán)的訪問。

建議——API 開發(fā)人員應(yīng)確保在構(gòu)建 API 時符合正確的標(biāo)準(zhǔn)，并且應(yīng)避免使用 API 密鑰進(jìn)行用戶身份驗證。還應(yīng)實施多因素身份驗證。

損壞的對象級別授權(quán)

損壞的對象級別授權(quán)是一種不安全的直接對象引用。當(dāng)未正確設(shè)置對象級權(quán)限時會發(fā)生這種情況，導(dǎo)致使用用戶輸入功能對資源進(jìn)行未經(jīng)授權(quán)的訪問。

建議——應(yīng)適當(dāng)管理用戶授權(quán)，特別是對于整個身份驗證過程中的登錄用戶。

批量分配

當(dāng)用戶可以通過利用特制請求來包含對應(yīng)用程序功能產(chǎn)生不利影響的參數(shù)來覆蓋服務(wù)器端變量時，就會發(fā)生批量分配。當(dāng)請求主體被解析為對象或利用某些框架級別的自動綁定功能（如 Spring 和 .NET）時，可能會發(fā)生批量分配。

建議——開發(fā) API 時不應(yīng)使用自動綁定功能。此外，限制可由客戶端修改的屬性。這可以防止將請求主體解析為對象。

參數(shù)篡改

當(dāng)攻擊者操縱在服務(wù)器和客戶端之間交換的參數(shù)（通常存儲在 cookie、隱藏的表單字段或 URL 查詢字符串中）以修改或竊取應(yīng)用程序數(shù)據(jù)時，就會發(fā)生參數(shù)篡改。

建議——Web 應(yīng)用防火墻可以防止參數(shù)篡改。將應(yīng)用程序輸入的格式列入白名單并加密會話 cookie 也有助于防止參數(shù)篡改。

結(jié)論

隨著 API 繼續(xù)被組織和個人廣泛用于軟件開發(fā)和集成，有必要了解與使用 API 相關(guān)的風(fēng)險。這些風(fēng)險主要與與 API 相關(guān)的漏洞一致。雖然幾乎不可能完全保護(hù) API 免受所有可能的攻擊形式，但了解針對 API 的眾所周知且頻繁的攻擊不僅有助于拓寬您對它們的理解，還可以讓組織在緩解這些攻擊時做出正確的決定。